[レポート] Amazon Redshiftの運用管理 #AWSSummit

AWS Summit Tokyo 2019 Day2 で開催された「Amazon Redshiftの運用管理」についてレポートします。

セッション情報

スピーカー：大薗 純平氏 （アマゾン ウェブ サービス ジャパン株式会社）

セッション名：Amazon Redshiftの運用管理

スケーラブルで高速な AWS のマネージドデータウェアハウスである Amazon Redshift は常に進化を続けており、日々のデータウェアハウス運用を楽にするような機能拡張も充実してきています。本セッションでは、Redshiftの運用管理にフォーカスし、考慮すべきポイントやTips、新しい機能の活用方法まで幅広くお話をします。

対象者

• 対象者
  • Redshiftを含むデータウェアハウスを運用している方
  • これからAmazon Redshiftを運用する可能性がある方
• 本セッションでの狙い
  • Amazon Redshiftの運用管理にまつわる最新のベストプラクティスを共有

自己紹介

• Redshiftのスペシャルソリューションアーキテクト
• お客様からのフィードバックを開発チームへフィードバックし、Redshiftを改善していく役割

アジェンダ

• Amazon Redshiftの概要
• Amazon Redshiftで変わるDWH運用タスク
• DWH運用課題とAmazon Redshiftのソリューション
• まとめ

Amazon Redshift の概要

• 高速、スケーラブルで費用対効果の高いデータウェアハウスおよびデータレイク分析マネージドサービス
• 高速
  • DWHに特化したRDBMS
  • 機械学習を搭載したオプティマイザエンジンを搭載
• スケーラビリティ
  • クラスターのノードを追加してスケールアウトできる
• データレイクへの拡張
  • DWHだけにとどまらずデータレイクへの接続もできる
• コスト
  • 従来の1/10のコストで運用できる
• Redshiftのアーキテクチャ
  • リーダーノード
    • データは持たない、クエリの受付、実行計画
  • コンピュートノード
    • データが格納されている
    • SQLがパラレルで実行される
  • Amazon Redshift Spectrum
    • S3へクエリが発行できる
    • サーバレスなのでユーザが管理する必要はない

Amazon Redshiftで変わるDWH運用タスク

• Amazon Redshiftで変わるDWH運用
  • バックアップ
    • S3への自動/手動スナップショットで劇的に改善
  • リストア
    • スナップショットからの復元。他のリージョンでも復元できる
  • 監視（システム/ワークロード）
    • コンソールやCLI経由で状況を確認
  • アクセス監視
    • 監査ログをS3へ自動取得
  • バージョンアップグレード
    • 定期的な自動アップグレード
    • 1週間に一度のメンテナンスウィンドウを指定
    • 機能が追加されたり、パフォーマンスが改善する
  • キャパシティ監視 など
    • 厳密な管理は必ずしも必要ではない（クラスターリサイズまたはS3データレイクへのアンロードが可能）
• Redshiftを使用することで多くのタスクが自動化、簡易化される

DWH運用課題とAmazon Redshiftのソリューション

• DWHの運用における課題
  • パフォーマンス維持管理の難しさ
    • スキーマもデータも変化する
    • 定期的なモニタリングと試行錯誤のチューニング作業
  • 上記に対応するためパフォーマンスの維持管理に役立つ自動機能を活用する
    • Auto Analyze、Auto Vacuum
    • Auto WLM
    • Analyze Compression / DISTSTYLE Auto
    • Amazon Redshift Advisor
  • ピークタイムのワークロード管理
    • バッチ処理の長期化によりオンライン処理への影響
      • ピークタイムのバッチ処理の高速化にはWLMの動的設定とElastic Resizeが有効
    • 同時アクセスの増加により、全体スループットの低下
      • Concurrency Scalingが有効

パフォーマンスの維持管理

• SQLクエリの見直し
  • 他の処理に影響が少ないのでまずやること
  • 必要なカラムのみ抽出するようにする
• クラスター構成の変更
  • リサイズによるスケールアップ/アウト
• テーブル論理設計の見直し
  • テーブルの非正規化
• 最低限やること → 最近は自動化機能の強化がされている
  • テーブルメンテナンス状況の確認
  • ワークロード管理設定の変更
  • テーブル物理設計の見直し
• 自動化されたDWH管理タスク
  • Auto Analyze
    • Analyzeは、最適なクエリ実行計画作成に必要なテーブル統計情報を更新する処理
    • テーブルデータの変化と、クエリの負荷状況に基づいて適切なタイミングで自動実行される
    • パラメータ auto_analyze を変更することで、自動実行をOFFにすることも可能
  • Auto Vacuum Delete
    • Vacuum DeleteはDeleteやUpdate後の削除領域の開放を行う処理
    • テーブル内の削除済み行数とクエリの負荷状況に基づいて適切なタイミングで自動実行される
    • 自動実行をユーザにて停止することは不可
    • Vacuum中にクエリがあるとクエリが優先される
  • Auto WLM
    • 従来のワークロード管理（WLM）では、ユーザ側でクエリに割り当てるメモリを手動で設定する必要があった
    • WLMの設定を自動化（Auto WLMを有効化）することでクエリへのメモリア割り当てを最適化するために並列スロット数を自動的に決定する
  • エンコーディング（圧縮）
    • 初回データロード時
      • COPYコマンドによるデータロード時に列ごとにエンコーディングタイプを自動的に設定することが可能（デフォルト）
    • 既存のテーブルに対して
      • ANALYZE COMPRESSIONコマンドで列ごとにエンコーディングタイプの推奨設定を確認し、再定義することが可能
  • AUTO分散スタイル
    • CREATE TABLE時のデフォルトの分散スタイルがEVENからAUTOへ
    • テーブルのサイズに基づいて分散スタイルを動的に変更
    • サイズが小さいうちはALL分散、サイズが増えるとEVEN分散へ自動変更
    • 一度 EVEN に変更されるとデータ容量が減ってもALLには戻らないので注意
• パフォーマンス改善のヒントを得る Amazon Redshift Advisor機能
  • パフォーマンスに関するアラートをマネージメントコンソール上のAmazon Redshift Advisor機能を通じて取得することが可能
  • Amazon Redshiftが自動でクラスターパフォーマンスや使用状況のメトリクスを分析しパフォーマンスの最適化や運用コスト削減のためのリコメンデーションを提供

バッチ処理の長期化

• ピークタイムのバッチ処理問題
  • バッチ処理は1時間毎、日次、週次、月次、年次などさまざまなサイクルで実行される可能性がある
  • 加えて、タイミング（季節性、イベント発生など）によって処理するデータ容量は変動しうる
• バッチ処理が長期化すると
  • ユーザへの最新データ提供が遅れる
  • インタラクティブな分析を実行するユーザの処理に影響が出る
• WLM機能を有効活用
  • リソースをバッチ処理に優先的に割り当ててバッチ処理の高速化を図り、ユーザ用の分析処理への影響も最小限に抑える
• Elastic Resizeを活用
  • クラスターを一時的にスケールすることでバッチ処理を高速化する

WLM機能を有効活用

• まずやること：WLMキューの分離
  • WLM（ワークロード管理）を利用することで、複数のビジネスワークロード間で使用するリソースを分離することが可能
  • ピークタイム時でも相互影響を与えたくない単位でキューを分け、メモリ割り当てサイズとスロット数（並列実行数）を決定する
• 例：バッチ処理とインタラクティブな分析処理
  • 通常時
    • キューを分ける
    • 分析ようにメモリサイズをより多く割り当てるなど
  • ピーク時
    • ピークタイムに備えて、より多くのリソースをバッチに割り当て
    • WLMリソース配分の動的変更
      • キューに割り当てるメモリサイズやスロット数は、状況に応じて動的に変更することが可能
      • 特に思い（I/Oインテンシブな）処理は、複数のスロットを割り当てて処理することも検討

Elastic Resize を活用

• 数分でクラスターをの伸縮を実現
• 既存のRedshiftクラスター上に、瞬時にノードを追加できる
• スケールアウト/インを数分で実現
• Elastic Resizeの実行手順
  • コンソール → サイズ変更クラスター
  • CLIコマンでで実行

同時アクセスの増加

• DWHワークロードの特徴
  • DWHには多様なユーザが様々なツールを使って接続する可能性がある
  • 評判のよいDWHは成長していく
  • BIダッシュボードからはバックグラウンドで複数のクエリが流れる
  • DWHは接続ユーザ数以上のリクエストを受ける可能性がある
• ピークタイムのワークロード
  • アクセスの集中する時間帯では、システム全体のパフォーマンス低下を引き起こす可能性がある
  • ピークタイムに合わせたDWHのリソースサイジングが必要になる
• Concurrency Scaling
  • バックグラウンドで追加のクラスターを追加できる
  • 仕組み
    • メインクラスターがリソース不足になると別のクラスターを追加
    • データは、常にS3上にバックアップ
    • 追加クラスターはスナップショットからデータをスキャンし、独自のキャッシュ機構を活用してクエリ処理
  • クエリを早くするものではなく、並列処理数を増やすもの
  • Concurrency Scalingを有効化する
    • WLMのキューのConcurrency Scaling mode 設定値をautoに設定
  • 追加クラスターの最大数を設定できる
    • パラメータ max_concurrency_scaling_clustersにて追加クラスターの最大数を0-10の範囲で指定（デフォルトは1）
  • Concurrency Scalingの適用条件
    • メインクラスターのタイプ
      • インスタンスタイプはdc2.8xlarge、ds2.8xlarge、dc2.large、ds2.xlarge
      • ノード数は2〜32まで
    • クエリタイプ
      • Amazon Redshift localテーブルまたはSpecgtrumテーブルに対するRead-Onlyクエリ（SELECT、Unload）
    • 例外
      • テーブルにInterleaved Sort Keyキーを使っていないこと
      • テーブルにユーザ定義のTemporary Tableを使っていないこと
  • Concurrency Scalingの価格
    • Redshift クラスターあたり、24時間につき1時間分、最大30時間分の無料クレジットが付与される
    • 無料クレジット分を超えて本機能を使用した場合のみ、追加クラスター毎にクエリが実行された期間（秒）に対して課金（最小1分）

Amazon Redshiftの運用管理まとめ

• 一般的なDWHで必要となる多くのタスクは自動化、簡易化されている
• パフォーマンスの維持管理に役立つ自動機能を活用する
• ピークタイムのバッチ処理の高速化には、WLMの動的設定とElastic Resizeが有効
• ピークタイムの同時アクセスの増加には、並列性能を向上できるConcurrency Scalingが有効